home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
AOL File Library: 9,300 to 9,399
/
9300.zip
/
AOLDLs
/
E-Zines
/
EZINE_ TidBITS#335 (MAC)
/
tb335.txt
< prev
Wrap
Text File
|
2014-12-11
|
31KB
|
587 lines
TidBITS#335/08-Jul-96
=====================
After a week off, we return with the second part of Geoff's
detailed look at the PowerPC chip and other bits of Macintosh
architecture. Adam weighs in with advice for people who have to
give Internet presentations, and Tonya looks at a couple of Web
browser plug-ins that help browsers both talk and listen, along
with a new mailing list called Disabled-Talk. MailBITS about the
release of the commercial System 7.5.3 and BBEdit 4.0.1 round out
the issue.
This issue of TidBITS sponsored in part by:
* APS Technologies -- 800/443-4199 -- <sales@apstech.com>
Makers of hard drives, tape drives, and neat SCSI accessories.
For APS price lists, email: <aps-prices@tidbits.com>
* Northwest Nexus -- 206/455-3505 -- <http://www.halcyon.com/>
Providing access to the global Internet. <info@halcyon.com>
* Power Computing -- 800/375-7693 -- <info@powercc.com>
PowerTower 180 MHz - the fastest Mac OS system ever made.
Win a PowerCenter 120! <http://www.powercc.com/>
* America Online -- 800/827-6364 -- <http://www.aol.com/>
The world's largest provider of online services.
Give Back to the Net -- <http://www.aol.com/give/>
* EarthLink Network -- 800/395-8425 -- <sales@earthlink.net>
Providers of direct Internet access for Macintosh users.
For eWorld refugees: no setup fee! <http://www.earthlink.net/>
* DealBITS: Great deals on Macs, utilities, and programming tools!
<http://www.tidbits.com/dealbits/> -- <dealbits@tidbits.com>
Copyright 1990-1996 Adam & Tonya Engst. Details at end of issue.
Information: <info@tidbits.com> Comments: <editors@tidbits.com>
---------------------------------------------------------------
Topics:
MailBITS/08-Jul-96
Plain Talk on the Internet
Presenting the Internet
Fishing For Chips: Part 2
<ftp://ftp.tidbits.com/pub/tidbits/issues/1996/TidBITS#335_08-Jul-96.etx>
MailBITS/08-Jul-96
------------------
**Apple's Call for Unity** -- Apple has finally released the
long-awaited retail version of System 7.5.3. This version can
install a universal system that will boot anything from a Mac Plus
onwards. Codenamed Unity, the retail version of System 7.5.3
includes the fixes from System 7.5.3 Revision 2 (see
TidBITS-332_), LaserWriter 8.3.4 (see TidBITS-333_), support for
8x CD-ROM drives, the Apple Internet Connection Kit, and an
optional installer for OpenDoc 1.0.4. The software costs $99 and
should be available shortly through the usual retail software
channels on floppy disk or CD-ROM; current System 7.5 owners can
upgrade for $49 by calling 800/293-6617, ext. 1 with proof of
ownership. For many Mac users and support personnel, installing
System 7.5.3 required running through an involved series of
installers, downloads, and patches - it's nice that Apple finally
put everything together in a single release, even if it will soon
be eclipsed by new versions of Open Transport and other system
components. Apple says international versions of Unity should be
available in the next 90 days. [GD]
<http://product.info.apple.com/pr/press.releases/1996/q4/
960702.pr.rel.macos.html>
**BBEdit 4.0.1 Update** -- Bare Bones Software released an update
to BBEdit 4.0.1, which includes improved HTML tools, the ability
to edit and store text files on an FTP server directly, and
(notably!) multiple undos. The update is free to existing BBEdit
4.0 customers; the update does not work with any version of BBEdit
Lite. [GD]
<ftp://ftp.barebones.com/pub/updaters/>
Plain Talk on the Internet
--------------------------
by Tonya Engst <tonya@tidbits.com>
Interested in interfacing with the Web using sound? Two browser
plug-ins, ListenUp and Talker, enable you to do just that. I've
used both plug-ins without crashes in both Netscape Navigator 2
and Internet Explorer 2 on my Power Macintosh 7100. Both plug-ins
require that you install PlainTalk, Apple's speech recognition
technology, which comes with Apple's System 7.5 and can also be
downloaded from various online venues.
<ftp://ftp.info.apple.com/Apple.Support.Area/Apple.Software.Updates/US/
Macintosh/System/PlainTalk_1.4.1/>
Written by Bill Noon, ListenUp 1.41 enables you to follow links by
speaking their names. There are a few catches: you must have a
Power Mac equipped with a PlainTalk microphone, run System 7.5 or
newer, and be following a link on a Web page specially coded to
work with ListenUp. In addition, you must be lucky enough to have
voice recognition usually work for you; I've only had moderate
success in this department. Web authors who wish to support
ListenUp must include a short bit of additional HTML on their
pages (for those in the know, that short bit is an <EMBED> tag),
and they must also place on their Web servers a text file that
associates link text with URLs.
<http://snow.cit.cornell.edu/noon/ListenUp.html>
In contrast to ListenUp, which helps Web browsers listen, Talker
2.0 makes Web browsers talk. The free plug-in from MVP Solutions
lets you hear the text displayed on Web page. A Talker-enabled Web
page displays onscreen in the normal, visual fashion, but your Mac
automatically speaks the words on the page. Web authors can even
set up pages such that different bits of text are spoken, or even
sung, in different voices. To use Talker, you must have the
English Text-to-Speech component of PlainTalk installed. The
Talker Read Me file helpfully discusses how to tell if you have
the right software installed, and what to do if you don't.
<http://www.mvpsolutions.com/PlugInSite/Talker.html>
TidBITS doesn't currently support ListenUp- or Talker-savvy HTML,
but I wouldn't rule it out for future issues. However, instead of
HTML authors adding special HTML tags to enable their pages for
speech, it would be nice to see more browsers support speech. For
instance, NCSA Mosaic 3.0b2 can speak the contents of pages
without requiring special HTML. A sufficiently savvy browser might
even have mannerisms like emphasizing text in <EM> tags or letting
you configure what voices speak when your Macintosh reads
differently tagged text. For instance, you might assign headings a
more authoritative voice than regular body text.
<http://www.ncsa.uiuc.edu/SDG/Software/MacMosaic/>
One TidBITS reader already uses PlainTalk and his PowerBook during
his daily commute in order to keep up with TidBITS and other
online periodicals. He's not a Mosaic user, so it takes some
setting up on his part, but apparently the time it takes to drive
from his home in Redmond to his office in downtown Seattle is just
long enough to listen to a complete TidBITS issue.
**Disabled-Talk** -- If your interest in interfacing with the Web
via sound has less to do with novelty and more with necessity, or
if you are generally interested in additional methods of
interacting with and using a Macintosh, you might wish to join the
new Disabled-Talk mailing list. The list's charter calls for
discussions to center on Mac-related techniques and technologies
that make life easier for people having disabilities or handicaps.
Such discussions might include information about using sound to
interface with a Macintosh, screen magnification, and using a Mac
to automate a variety of tasks, such as turning on lights.
<http://thelorax.res.cmu.edu/lists/disabled.html>
Presenting the Internet
-----------------------
by Adam C. Engst <ace@tidbits.com>
I've been giving a number of talks recently at conferences like
the Adobe Internet Solutions Conference, and I thought I'd share
some of the tricks and techniques that I've worked up for Internet
presentations.
While I was a student at Cornell, my part time job involved
managing a seminar room with a projector. I've seen (and rescued)
far too many demonstrations undermined by technical glitches. As a
result, I tend toward extremely low-tech presentations. Short of
laryngitis, there's not much that can go wrong if you're just
talking. Add an overhead projector and the bulb could blow; use a
Macintosh and the projector can mess things up in any number of
ways, not to mention all the potential problems of using an
unfamiliar Mac with unexpected fonts and extensions. Add a live
Internet connection and you're tempting the laws of Murphy
(whatever can go wrong, will).
So, my main advice for any presentation is to keep the level of
technology involved to a minimum. Obviously, since we're talking
about Internet presentations, that's difficult, so the corollary
is that when you must do a high-tech presentation, isolate and
eliminate as many variables as possible. If you have your own
PowerBook and can connect to the projector, use your PowerBook
rather than whatever Macintosh might already be there. If you have
your own modem, ditto. Anything you can do to stick with a known,
working situation rather than venturing into the unknown reduces
your chances of blowing the presentation.
For Internet presentations these days, I've had extremely good
luck with doing my "slides" in HTML rather than in a program like
Persuasion or PowerPoint. Aside from the fact that I don't use
either of those programs, HTML is extremely flexible. For
instance, I can put my presentation up on my Web server as a
backup in case something happens to the copy I bring with me. I've
never needed that backup, but making slides in HTML also
simplifies showing off a variety of Web sites as part of the
presentation - just click and you're there. I've made HTML slides
for presentations a few times now, and they tend to be extremely
simple. Each slide usually contains a small graphic at the top and
then a short list of points. The slide finishes with Next and
Previous links for moving around. You can make links all over in
your presentation, but I recommend keeping it mostly linear
because it's too easy to become flustered while you're on stage.
The way I create my slides is a little unusual. Working from an
outline, I go straight through the talk, creating the HTML file
for each slide as I go. I name the first file something like
"connect1.html" and when I'm done with that one, I duplicate it in
the Finder, rename it to "connect2.html" and edit it, which is
easier and more consistent than trying to do each one from
scratch. Get the first one right, or else you'll have to make
changes in all the files after that point. Small changes aren't a
problem if you use a tool like BBEdit or NisusWriter that can find
and replace across all the files in a presentation. I've seen
other HTML slide presentations done as a single long HTML
document, which you can either scroll through or use internal
anchor links.
If you plan to show examples of Web sites during your
presentation, consider using WebWhacker from The ForeFront Group
to download some of the site, complete with graphics and internal
links. That way, if your Internet connection isn't working when
you give the presentation, it won't matter. It's often a good idea
to make two links for each sample site, a local one to the
downloaded version of the site and a remote one to the online
version of the site, because there are times that you might not
have downloaded the part of the site you need. More importantly,
sometimes it's good to show the real speed of the site, rather
than the speedy canned demonstration from your hard disk.
<http://www.ffg.com/whacker.html>
Another reason to use HTML for your presentation is that it
provides a variety of options for which browser you use. Unless
you present sites that rely on Netscape extensions, for instance,
it doesn't matter all that much. Tonya likes using MacWeb because
it provides much more control over onscreen fonts and styles than
Internet Explorer or Netscape Navigator. Speaking of fonts, when
you test your HTML at the site of the presentation with the
projector on, make sure the font you use is readable from the back
of the room. Netscape, for instance, defaults to using Times 12
point for its text font, which is small and hard to read onscreen.
I usually switch to New York 12 point, which is easier on the eyes
and designed for onscreen readability. If you use separate HTML
files for each slide, run through your entire presentation to
ensure you'll have a minimum of scrolling - scrolling distracts
you from the task at hand, which is speaking.
No matter what, shut off as many of the toolbars and other fields
at the top of the window as you can. No one will be able to read
the Location field, and if your presentation is local, the URLs
will be useless anyway. Things like Netscape's Directory Buttons
are pointless for the purposes of the presentation, and take up
screen space your slides could use to avoid scrolling. Also, many
people in your audience may not be able to see the bottom third of
the screen, so you'll want your information to be up at the top
where everyone can see it. This may seem like a minor point, but
you don't want to waste screen space or distract your audience
with unnecessary screen controls, and few presenters seem to
realize this.
Since no one can see the URLs for the sites you visit, make sure
to include them on a handout for the audience. It's a good idea to
provide a handout anyway, since that keeps people from madly
taking notes when they should be paying attention to what you're
saying. For some reason, audiences are always desperate to know
exactly what URLs you've visited, and URLs are deucedly hard to
convey in spoken words.
I don't want to get into the details of actually making the
presentation, other than two quick points. First, if you only have
a modem connection, don't apologize for its speed, or, if you
must, only apologize once. Second, when you take questions from
the audience (which you definitely should do, but only at
appropriate breakpoints and again at the end), make sure to repeat
the question before answering it. Failing to repeat the question
so everyone can hear it before you answer is probably the most
common failing of technical presentations.
Fishing For Chips: Part 2
-------------------------
by Geoff Duncan <geoff@tidbits.com>
In TidBITS-334_, we looked at the PowerPC processor family and
some of the terms and technologies associated with it. If you read
the article, your probably know the difference between 68K and
PowerPC chips, why clock speed and clock multipliers are
important, the difference between Level 1 and Level 2 caches, and
the differences among different PowerPC chips. Part 2 builds on
this information and examines additional software and hardware
components of the Power Macintosh.
**Emulators Forever** -- If there's a single thing that made the
Power Macintosh successful, it's the 68K emulator built into its
system software. Conceptually, the 68K emulator sits between the
PowerPC processor and executing code. If code is written for the
PowerPC (such code is considered "native"), the emulator does
nothing; if the code is written for 68K machines, the emulator
translates it to PowerPC code (at a very low level) and passes it
to the PowerPC processor. Without a 68K emulator, non-native
programs wouldn't run at all on a Power Mac.
The 68K emulator enabled Apple to move the Macintosh to a new
processor architecture while retaining strong compatibility with
existing programs - undeniably a good thing. At the same time, 68K
emulation is also the Achilles heel of the Power Mac because the
performance of 68K emulation can't compare to that of native
PowerPC code. When the Power Macs were introduced, Power Mac users
often took a step backward in performance because the vast
majority of Mac software was only available for 68K machines.
Though some native applications appeared quickly, major tools like
QuarkXPress, Microsoft Office, and FileMaker Pro took a while to
become Power Mac-native.
Further, though Apple has ported many critical portions of the
system software to take advantage of the PowerPC, much of the
system still relies on the 68K emulator. Thus, even high-end Power
Macintoshes are caught in a quagmire of 68K code, reducing their
potential real-world performance even when running native
applications.
If 68K code is so slow, then how long will 68K emulators be
around? That's simple: Apple has to keep a 68K emulator in the
system forever.
First, the Mac OS relies heavily on the 68K emulator, and though
System 8 will contain substantially more Power Mac-native code
than System 7.5.3, it's unlikely the entire operating system will
ever be fully native. At a basic level, it's not worth the effort
to port everything, particularly little-used, non-performance-
related portions of the system.
Second, Apple has a vested interest in making sure 68K code and
applications continue to run. Almost every Power Mac user owns
software written for 68K machines that will never be ported to
PowerPC. A good example is Ambrosia Software's arcade classic
Maelstrom, which is largely written in 68K assembly language.
Porting Maelstrom to the PowerPC would be an enormous undertaking;
yet, more than two years after the introduction of the Power
Macintosh, Maelstrom continues to run fine in emulation, and is
actually a good test of 68K emulators.
<http://www.ambrosiasw.com/Ambrosia_Products/Maelstrom.html>
Keeping 68K emulation in the system doesn't mean that improvements
can't be made. Apple's original 68K emulator was static,
translating 68K instructions to PowerPC code one at a time.
Emulation performance can be improved with larger Level 1 or Level
2 processor caches (emulator performance is better on the PowerPC
603e chip than the original 603 due to a larger Level 1 cache);
however, it's also possible to build a smarter emulator.
With the PCI Power Macs, Apple introduced a significantly faster
dynamic recompilation (DR) emulator. The DR emulator watches the
68K code for loops and stashes the translated PowerPC code for
later use, rather than translating the same 68K instructions over
and over again. However, the DR emulator comes with a slightly
higher price in terms of compatibility: programs that do not
operate correctly on 68040 machines with their processor caches
enabled may not run correctly. Also, Apple's DR emulator only
works on PCI Power Macs; the ROMs of earlier Power Macs don't
support it.
A good alternative is Speed Emulator, part of Connectix's Speed
Doubler. (See TidBITS-292_.) Speed Emulator is also a DR emulator,
and though it uses more memory than Apple's, it also significantly
outperforms it and runs on any Power Mac. Speed Emulator's
additional performance is particularly obvious in some areas; for
instance, it significantly speeds up the Apple Event Manager, a
feature particularly appreciated by AppleScript users.
<http://www.connectix.com/>
Both Apple's and Connectix's emulators imitate a 68LC040, which is
a problem if you need to use a 68K program with a program that
specifically requires a floating point unit (FPU). In the 68K
family, FPUs were originally a separate chip devoted to floating
point math operations. With the 68040, Motorola built most FPU
functions directly into the processor, then (in a cost-cutting
move) removed them in the 68LC040. Programs requiring an FPU won't
run under emulation on a Power Mac because they correctly
determine that an FPU isn't available.
If you need to use programs requiring an FPU on a Power Macintosh,
you have two choices: SoftwareFPU and PowerFPU, both from John
Neil and Associates. These programs emulate a 68K FPU, allowing
68K programs that require an FPU to function. SoftwareFPU, a $10
shareware product, works fine, though it's not PowerPC native and
must pump its math calls through the 68K emulator. PowerFPU is a
$20 commercial product that provides PowerPC-native FPU emulation.
Since native PowerPC floating point functions are speedy,
PowerFPU's performance can be quite good.
<http://www.jna.com/>
**The Magic Bus** -- When evaluating the performance of a
computer, most users refer to the machine's processor type and
clock speed, primarily because these terms are common,
occasionally comparable, and liberally used in marketing
materials. However, another major factor in a computer's overall
performance is its bus, the main data path between the processor
and other components.
The easiest way to explain a bus is by analogy: think of your
computer as a small, one-road town. Most of your computer's
components live on the road, and the road must be used every time
information has to travel between components. A traffic light
controls travel, and a complex series of local laws governs who
can go ahead, who has to wait, and how often people can get on or
off the road. Two things control how _fast_ traffic moves: how
many lanes the road has ,and how often the traffic light changes.
One thing controls how _efficiently_ traffic moves: local traffic
laws.
In this analogy, the bus width is the number of lanes in the road,
the bus speed is how often the traffic light changes, and the
hardware architecture and operating system are the traffic laws.
* Bus Width: The bus width is literally how many bits can move
across the bus at the same time. Power Macs have a 64-bit bus,
meaning 64 bits can travel across the bus simultaneously. Previous
Macs had a 32-bit bus, and early Macs had a 16-bit bus. As you
might expect, a 64-bit bus is about twice as fast as a 32-bit bus,
since it can move twice as much material in the same amount of
time. However, a 64-bit bus is also more expensive to manufacture.
* Bus speed: The clock oscillator controls bus speed, as well as
processor speed. Basically, a clock oscillator is a tiny quartz
crystal that vibrates a certain number of times per second. It's
like a metronome for a computer, controlling everything from disk
access and screen redraws to memory access and networking, and
making sure everything happens in sync.
* Hardware architecture: How traffic flows over the bus is a
function of the computer's hardware and operating system design.
For example, in older computers, writing data from RAM to a disk
meant every piece of information in RAM had to go across the bus
to the processor, then back across the bus to the disk system,
which would write the information and report back when it
finished. These days, it's more common for computers to have a
"private road" between RAM and disks. There are numerous other
instances of hardware and software engineering in all Macintosh
models that strive to improve bus efficiency.
**Dishing Your Buses** -- The analogy above is a vast over-
simplification - in reality, a Macintosh has a number of different
buses, most of which exist in sub-systems. SCSI, Ethernet, serial
ports, RAM, expansion slots (NuBus and PCI), and input devices all
have separate buses, each of which has its own width and
(sometimes) its own oscillator.
Bus speed is an important factor when considering upgrades. Clock
chipping, a popular, inexpensive method for upgrading Quadras and
first-generation Power Macs, involves replacing the computer's
clock oscillator with a faster one. Although it invalidates
Apple's warranty and not all Macs can be clock chipped
successfully (success rates are around 90 percent), replacing the
clock chip speeds up the computer's processor and bus, often
making for a good all-around performance improvement. For detailed
information on clock-chipping, check out Marc Schrier's clock
chipping FAQ.
<http://violet.berkeley.edu/~schrier/mhz.html>
Many PCI Power Macs and clones have both their clock oscillators
and processor chips on a removable CPU daughter card, providing a
built-in upgrade path to faster clocks and processors. This design
permits you to replace the processor and the clock oscillator at
the same time. However, in many cases there's still a limit to how
fast the main bus can go. In Apple's current models, the upper
limit is 50 MHz; Power Computing's PowerTowers go to 60 MHz. This
doesn't mean that daughter card upgrades won't be worthwhile for
these machines, but rather that they won't improve the performance
of every aspect of the system beyond a certain point.
Similarly, upgrade cards for from vendors like Apple and DayStar
for earlier Mac models (from the IIci through the Quadra series)
should be evaluated not only on the basis of the promised clock
speed of the PowerPC chip, but also in terms of the performance
constraints imposed by other hardware. In many cases, these cards
must traverse a comparatively slow, narrow bus to get data from
disks, ports, other devices, and/or RAM, yielding real-world
performance levels considerably lower than Power Macs with
equivalent processor speeds. Though these upgrades might be
adequate for being able to run PowerPC code, they're rarely
equivalent to the performance of a used Power Mac and often cost
just as much.
**The Myth Of Clock Speed** -- In the end, what does all this mean
for buying a Macintosh these days?
Be wary of hype surrounding the raw clock speed of a particular
machine. Although processor speed is (of course) related to
performance - and many computer vendors trumpet little more than
the clock speeds of their machines - many other factors (processor
type, cache, emulation, bus speed, system software, and more)
contribute to a machine's real-world performance.
As an example, Power Macs achieve their high processor speeds by
using clock multipliers built into their PowerPC processors,
allowing the chips to run faster than the machine's clock
oscillator. There's no question this improves performance, but
there are limits to how much bang-for-the-buck this technique will
produce. There's a real performance difference between a 120 MHz
machine using a 6x clock multiplier on 20 MHz bus and a 120 MHz
machine using a 2x clock multiplier on a 60 MHz bus. Though both
machines would function, the first machine will take much more
time to access disks, networks, memory, and peripheral cards than
the second machine. Even though they'd be roughly equivalent in
terms of raw processor performance, the first machine is going to
spend more of its processor cycles waiting for its hardware.
Also, pay attention to what processor a particular machine uses.
In terms of raw processor power, a 120 MHz PowerPC 604 is
significantly (50 to 75 percent) faster than a 120 MHz PowerPC 601
or 603e, just by the nature of the chip designs. However, in real
world terms, a machine with a PowerPC 604 might only mildly
outperform a 120 MHz 603e with a fast bus, fast video, fast disks,
and a good emulator.
If you can't judge computers by their clock speed, what can you
use? Increasingly, the only meaningful measures of real-world
performance are produced by benchmark applications like
Speedometer, MacBench, and Norton Utilities System Info.
<ftp://mirror.aol.com/pub/info-mac/cfg/speedometer-402.hqx>
<http://www.zdnet.com/zdbop/macbench/macbench.html>
I don't feel the results of these programs can be accepted as
gospel. Though tests on my Macs produced results in the right
ballpark for each machine, none of these applications produced
consistent results in repeated testing. Still, programs like these
at least attempt to analyze more than a processor's performance,
and if results are sufficiently averaged across a wide range of
configurations, they might give a reasonable idea of a machine's
real-world performance.
**For More Information** -- These two articles have covered a lot
of territory, and I hope they dispelled some confusion about what
different bits of hardware do and how you can relate their
specifications to real world performance. If you'd like more
information, I'd recommend the following technical sources.
For details on PowerPC processors, look at Motorola's and IBM's
information, as well as the PowerPC FAQ:
<http://www.mot.com/SPS/PowerPC/library/library.html>
<http://www.chips.ibm.com/products/ppc/index.html>
<http://www.mot.com/SPS/PowerPC/library/ppc_faq/ppc_faq.html>
If you're interested in how processors are officially benchmarked
(and what a SPECint95 means!), check with the source:
<http://www.specbench.org/>
Finally, if you're curious about how the PowerPC chip works in the
middle of a Macintosh, I recommend this introduction from Apple's
Developer University:
<http://dev.info.apple.com/du/intro_to_ppc/ppc0_index.html>
$$
Non-profit, non-commercial publications may reprint articles if
full credit is given. Others please contact us. We don't guarantee
accuracy of articles. Caveat lector. Publication, product, and
company names may be registered trademarks of their companies.
This file is formatted as setext. For more information send email
to <setext@tidbits.com>. A file will be returned shortly.
For information on TidBITS: how to subscribe, where to find back
issues, and other useful stuff, send email to: <info@tidbits.com>
Send comments and editorial submissions to: <editors@tidbits.com>
Issues available at: ftp://ftp.tidbits.com/pub/tidbits/issues/
And: http://www.tidbits.com/tb-issues/
To search back issues with WAIS, use this URL via a Web browser:
http://wais.sensei.com.au/macarc/tidbits/searchtidbits.html
-------------------------------------------------------------------